feat: support input database without patient extensions #220
Conversation
mikix
force-pushed
the
mikix/patient-extensions-low-schema
branch
from
0d0b56e to
14780bc
Compare
| PARTITION BY id, system | ||
| PARTITION BY id |
There was a problem hiding this comment.
This is a bug fix, afaict - when you have both ombCategory and detailed, this was partitioning in such a way that both would have available_priority = 1 and both show up in the extension table. Then when you joined with patients, you'd get duplicate patient rows.
There was a problem hiding this comment.
i don't think that's a bug - it's left to the study author to determine the appropriate system for their use case. the core study preserves what it finds, and the user should use distinct() on patient IDs when they're counting
There was a problem hiding this comment.
We talked about this on slack - we think it is a bug, and will leave the code change in. But we have lots of questions about best approaches for race/ethnicity. Should race_detailed be a separate column? What to do with text? Problems for another day.
mikix
force-pushed
the
mikix/patient-extensions-low-schema
branch
from
14780bc to
2f65227
Compare
mikix
force-pushed
the
mikix/patient-extensions-low-schema
branch
5 times, most recently
from
8533410 to
45da810
Compare
There was a problem hiding this comment.
Afaict, this changed due to a re-run of the regression ETL on updated sample-bulk-fhir-datasets data (we inlined some medication codes in Aug '23)
| @@ -153,7 +153,6 @@ CREATE TABLE core__documentreference AS | |||
| WITH temp_documentreference AS ( | |||
| SELECT DISTINCT | |||
| dr.id, | |||
| dr.type, | |||
There was a problem hiding this comment.
are there some dangling changes from a previous PR in here?
There was a problem hiding this comment.
Yeah, looks like I forgot to run generate-sql at the tail end of my deep-schema-support PR, after review changes.
| PARTITION BY id, system | ||
| PARTITION BY id |
There was a problem hiding this comment.
i don't think that's a bug - it's left to the study author to determine the appropriate system for their use case. the core study preserves what it finds, and the user should use distinct() on patient IDs when they're counting
Features: - The core__patient no longer requires the presence of race/ethnicity extensions to build (it now uses the deep-schema checking code) Bug Fixes: - If there are both detailed and ombCategory values for an extension, no longer report both - just prefer the ombCategory version.
mikix
force-pushed
the
mikix/patient-extensions-low-schema
branch
from
45da810 to
f278bba
Compare
Features:
Bug Fixes:
Checklist
docs/) needs to be updated